-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added ResendConfirmation GraphQL method. #35
Added ResendConfirmation GraphQL method. #35
Conversation
Much better, thanks for fixing your commits. I will review both PRs as soon as I have some free time. Just a note on this one, it also contains the changes to the docs you included in the other PR. This one should ONLY be about the resendConfirmation mutation. No need to close the PRs, they can always be fixed. |
Ok, got it! Yeah I also noticed that. A throwback from when I did my documentation work on |
If you notice, I added documentation for the |
Updated documentation for the mutation and query graphql methods.
I merged the #34, you need to resolve conflicts on this branch because of that. I still have to review the resend confirmation mutation, but on the mean time you could cleanup the readme, it should also include docs for the new mutation (just add it to the list as the others) |
…ql_devise into resend_confirmation Conflicts: README.md
Why did you close this one? Please don't open another one just because of git conflicts. Fix your branch locally and push to this same branch. you can push force |
Sorry after I updated my feature branch it looked like the other branch with a bunch of changes and I thought wouldn't want that so I was trying to fix it so it was a clean push. I'll fix this. |
When I looked at the changes files, it had files that I didn't change (see https://github.com/graphql-devise/graphql_devise/pull/35/files). It looks like I'm trying to add the Issue configuration files but thats from another PR that someone else did. |
Ok All the code in this PR is exactly what I want to add to the master branch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Thanks for the PR. Left some comments, let me know if you have questions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aarona could you add test to know what would happen if the email provided belongs to a user that is already confirmed? How devise behaves in this case?
Yes, thats a really good idea and I was considering that. I wanted to ask you guys if you had any other scenarios to test for. I'm going to sit down tonight and work on these changes. |
Just bumping this PR. I've made the changes you guys had requested. |
Thanks! I will take a look ASAP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aarona left a couple comments for you, this is looking good :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking great @aarona. Just some small changes to address, PR is getting there.
if resource | ||
yield resource if block_given? | ||
|
||
raise_user_error("Email #{I18n.t('errors.messages.already_confirmed')}") if resource.confirmed? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why interpolate a localized string here? Just put the entire string in the locales file please
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason why I did this is because it seemed you wanted to fall back on Devise locales. The errors.message.already_confirmed value is: "was already confirmed, please try signing in"
. I can make this whole thing as a locale entry but I'll have to put it into the graphql_devise
locale. Would you prefer that instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes please, move the entire message to our own locales file. I think the rule for localized messages should be that ANY message we use directly in OUR code, should go in our locales file. Otherwise we depend on the other gems to keep those keys on their locales files, if for any reason a version of those gems changes the messages, it could affect our gem. I'll have to check the rest of the code for the same thing, but for this PR, please make sure any localized message YOU use in the code has an entry in our locales file (the entire message always as some languages might have a completely different way to say something)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes check the /app/views/graphql_devise/mailer/reset_password_instructions.html.erb
file because it also relies on Devise's locale file. I can create a seperate PR for that and fix that.
I'll fix mine and update this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually it looks like both mailers do this. I'll create a PR for both later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good @aarona I think the locales thing is the most important one to take care of now, just make sure any message you are using comes from an entry on our locales file. Other small style comments and should be good to merge
if resource | ||
yield resource if block_given? | ||
|
||
raise_user_error("Email #{I18n.t('errors.messages.already_confirmed')}") if resource.confirmed? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes please, move the entire message to our own locales file. I think the rule for localized messages should be that ANY message we use directly in OUR code, should go in our locales file. Otherwise we depend on the other gems to keep those keys on their locales files, if for any reason a version of those gems changes the messages, it could affect our gem. I'll have to check the rest of the code for the same thing, but for this PR, please make sure any localized message YOU use in the code has an entry in our locales file (the entire message always as some languages might have a completely different way to say something)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job, thanks! I will review all locales in the gem and then release a new version with your changes 🙌
No description provided.